Application Number: 09/280,609 

Reply to Final O.A. of September 29, 2004 



Docket: 6402 



REMARKS/ARGUMENTS 

Claims 1 1-23 and 41-54 are pending in this application. Claims 1 1-23 and 41-53 have 
been rejected, and claim 54 has been added. Claims 11, 21-23, 41, 43, 47, and 49 have been 
amended, and such amendments are fully supported by the originally filed specification and 
drawings. Applicant respectfully requests reconsideration of this application and review of the 
below arguments. 

Rejection Under 35 U.S.C. $103 

Claims 1 1-23 and 41-53 were rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Puri with Patent No. 6,064,982 in view of Christenson et al. with Patent No. 5,926,817. 
The references fail to teach or suggest all of the claim limitations as required by MPEP § 2143. 
For at least this reason, Applicant respectfully requests that the rejection be withdrawn. 

Independent claims 1 1 and 43 recite downloading a subset of available viability-checking 
tools from a server to a client, eliciting selection of product attributes from a user, performing 
preliminary viability checking on the client of those selected attributes based on the subset of 
tools, and then performing a full viability check of the selected attributes on the server. See , 
claim 1 1 ("downloading to the client from the server only limited configuration information that 
is a subset of the full set of configuration information. . .preliminarily checking the viability of 
the desired technical configuration of the desired product. . .wherein the limited configuration 
programs verify conformity of the user selections for the option attributes with the limited option 
rules. . .performing a full check at the server on the viability of the desired technical 
configuration, wherein the full set of configuration programs verify conformity of the user 
selections for the option attributes with the full set of option rules"); see also , claim 43 
("transmitting only a limited configuration engine to the client. ..preliminarily checking the 
viability of the vehicle configuration of the desired vehicle at the client, wherein the client 
verifies the conformity of the user selections for the limited set of option attributes with the 
limited set of option rules. . .performing a full viability check of the vehicle configuration at the 
server, wherein the software of the full configuration engine verifies conformity of the user 
selections for the limited set of option attributes with the full set of option rules"). 
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Puri and Christenson fail to teach or suggest these limitations. Puri, which allegedly 
teaches these limitations, discloses a "smart configurator" that determines the viability of 
products ex ante and then offers those products to the user for selection (Fig. 5) rather than 
accepting elicited product attributes from a user and then checking those attributes ex post for 
viability as claimed. See, e.g. . Col. 3, lines 61-66 ("...the smart configurator determines the 
appropriate hardware requirements to run the software in an acceptable fashion (108) and 
displays this information on the workstation display"); Col. 5, lines 13-15 ("as generalized 
statements are selected until the smart configurator suggests more specific statements until the 
customer's needs are thoroughly and accurately assesse. [sic]"); Col. 5, lines 63-65 ("The actual 
hardware requirements for a particular software solution are automatically determined by the 
smart configurator "). Nowhere does the reference teach or suggest first eliciting from a user 
actual product attributes — as opposed to the "customer needs" — and then performing preliminary 
and full viability checking on those attributes. Further, Christenson does not teach or suggest 
modifying Puri to achieve this limitation. 

The cited references further fail to teach or suggest performing two distinct stages of 
viability checking: (1) a first stage of preliminary checking performed on a client with a subset of 
tools downloaded to the client from a server, and (2) a second stage of checking performed on 
the server with a full set of tools. Examiner cites to Puri at col. 6, lines 20-22, as teaching this 
latter stage, i.e., the full viability check ("the smart configurator provides a proposal template 
that merges various customer related information into a generic proposal."). However, nowhere 
does the reference teach or suggest the smart configurator performs this step on a server and 
performs a distinct preliminary check on a client as claimed. Moreover, the reference fails to 
teach or suggest performing two distinct stages of viability checking on user-selected product 
attributes , as claimed, as opposed to smart configurator-selected attributes. Further, Christenson 
does not teach or suggest modifying Puri to achieve this limitation. 

For at least the forgoing reasons, claim 54 is also allowable. 
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For at least these reasons, this application now stands in allowable form and 
reconsideration and allowance is respectfully requested. 



Respectfully submitted, 

DORSEY & WHITNEY LLP 
Customer Number 25763 



Min (Amy) S. Xu, Reg. No. 39,536 
Intellectual Property Department 
Suite 1500 
50 South Sixth Street 
Minneapolis, MN 55402-1498 
(612) 752-7367 



Date: 





4842-9494-45 12\1 2/25/2005 2:16 PM 



-11- 



